chore(ci): bump actions to node24, add Chrome token script - #139

Summary

Three pieces of CI maintenance: getting off the deprecated Node 20 action runtime, working around the broken wxt submit init, and automating the release back-merge.

Changes

Actions moved off the deprecated node20 runtime

GitHub is forcing node20 actions onto node24 and warning on every run. Bumped to the latest majors, all of which declare using: node24:

Breaking changes were checked and none affect this repo. checkout v5 only raises the minimum runner version, which GitHub-hosted ubuntu-latest already exceeds. setup-node v5 adds automatic caching when package.json declares a packageManager field — ours does not, so the explicit cache: "pnpm" still governs. pnpm/action-setup v5/v6 are purely the node24 move.

scripts/chrome-refresh-token.ts

Mints a Chrome Web Store refresh token. wxt submit init is supposed to do this, but it is currently unusable:

• it requests redirect_uri=urn:ietf:wg:oauth:2.0:oob, the out-of-band flow Google blocked in 2022 — it fails with Error 400: invalid_request
• its auth URL omits access_type=offline, without which Google returns only an access token and no refresh token at all

This is what broke the v1.8.0 Chrome publish (invalid_grant). The script uses the loopback redirect that replaced OOB, and requires an OAuth client of type Desktop.

read -rsp "Client secret: " S && echo && CHROME_CLIENT_ID=<id> CHROME_CLIENT_SECRET="$S" pnpm chrome:token

This script can be deleted once wxt submit init is fixed upstream — noted in the file header.

Branching model: dev -> main becomes a merge commit

Not a file in this PR, but the reason back-merge.yaml is absent from it.

A squash merge writes a new commit to main with no parent link to dev, so Git's merge base freezes and the next release re-proposes every commit main already has. That is what produced the conflicts before v1.8.0, and the -s ours reconciliation that followed.

A merge commit keeps dev's tip as a parent, so merge-base(main, dev) advances on every release and the branches cannot drift. Repo settings changed accordingly:

• allow_merge_commit: true
• required_linear_history: false on main

Squash stays the rule for feature -> dev (one tidy commit per feature). Merge commit is used only for dev -> main, the one merge that must preserve ancestry.

This removes the need for a back-merge workflow and a BACKMERGE_TOKEN PAT entirely, rather than automating the repair.

Removed paths: filters from unit and e2e

A workflow skipped by a path filter never reports a status, so a required check would sit on "Expected" and block the PR permanently. These have to run unconditionally before they can safely be made required. Cost is ~30s and ~45s per PR.

This same trap already exists on css-selectors, which is required and path-filtered — see below.

Testing

• All seven workflow files parse as valid YAML
• Token script verified: correct auth URL with access_type=offline and prompt=consent, loopback redirect, clean error when credentials are absent
• 87 unit tests, pnpm check, pnpm format:check all pass

Follow-up (not in this PR)

1. Add unit and e2e to required checks on main and dev — safe only after this PR merges and removes their path filters.
2. css-selectors is required and path-filtered, so a docs-only or workflow-only PR to main is currently unmergeable: a skipped workflow never reports a status, so the check sits on "Expected" forever. It is also a live canary against royalroad.com, so an outage there blocks merging. Worth moving it to a nightly schedule: and dropping it from the required set — it is monitoring, not a merge gate.
3. Use "Create a merge commit" for the next dev -> main release, now that the setting allows it.